[rlp-v2] WasmPlugin reconciliation #204
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
guicassolato
force-pushed
the
rlpv2-routeselectors
branch
6 times, most recently
from
3a1d470 to
62a4a43
Compare
guicassolato
added
kind/enhancement
alexsnaps
reviewed
Jul 10, 2023
| @@ -94,6 +94,35 @@ func (r *TargetRefReconciler) FetchValidTargetRef(ctx context.Context, targetRef | |||
| return nil, fmt.Errorf("FetchValidTargetRef: targetRef (%v) to unknown network resource", targetRef) | |||
| } | |||
|
|
|||
| // FetchAcceptedGatewayHTTPRoutes returns the list of HTTPRoutes that have been accepted as children of a gateway. | |||
| func (r *TargetRefReconciler) FetchAcceptedGatewayHTTPRoutes(ctx context.Context, gwKey client.ObjectKey) (routeKeys []gatewayapiv1beta1.HTTPRoute) { | |||
There was a problem hiding this comment.
Not that I am asking for anything to happen here or now, but…
Would such functionalities (or the ones in pkg/common/gatewayapi_utils.go) eventually get moved to Kuadrant/gateway-api-machinery ?
There was a problem hiding this comment.
Absolutely yes, @alexsnaps! Not doing it now just because this change goes to the RLPv2 feature branch first and we haven't moved main to using the gateway-api-machinery yet.
Alternative verification stepsAlternative verification steps for a rather complex scenario – with 2 Gateways, 3 HTTPRoutes and 4 RateLimitPolicies. IntroDisclaimerPlease keep in mind that we are implementing Direct Policy Attachment and not yet Inherited Policy Attachment. I.e.,
TopologyDescription of the network resources
State transitionsAfter setting the topology as described above, each RLP (from 1 to 4) will be created in sequence. This will trigger (4x) the reconciliation of the A WasmPlugin contains the configs for the RLPs and corresponding affected HTTPRoutes, according to the Similarly, and for all the other RLPs and affected HTTPRoutes, the table below describes the expected states of the WasmPluging CRs after the creation of each policy.
Expected final stateAfter the creation of all RLPs, any additional event that does not change the topology reconciles the following final state:
At the final state, the following back reference annotations are expected to be found in each of the targeted network resources:
Steps ① → ⑦① Setupmake local-setup
kubectl -n kuadrant-system apply -f - <<EOF
apiVersion: kuadrant.io/v1beta1
kind: Kuadrant
metadata:
name: kuadrant
spec: {}
EOF
kubectl apply -f examples/toystore/toystore.yaml② Create the Gatewayskubectl -n istio-system apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: gw-1
annotations:
kuadrant.io/namespace: kuadrant-system
networking.istio.io/service-type: ClusterIP
spec:
gatewayClassName: istio
listeners:
- name: websites
port: 80
protocol: HTTP
hostname: '*.website'
allowedRoutes:
namespaces:
from: All
- name: apis
port: 80
protocol: HTTP
hostname: '*.io'
allowedRoutes:
namespaces:
from: All
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: gw-2
annotations:
kuadrant.io/namespace: kuadrant-system
networking.istio.io/service-type: ClusterIP
spec:
gatewayClassName: istio
listeners:
- name: local
port: 80
protocol: HTTP
hostname: '*.local'
allowedRoutes:
namespaces:
from: All
EOF③ Create the HTTPRouteskubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: route-1
spec:
parentRefs:
- namespace: istio-system
name: gw-1
hostnames:
- "*.toystore.website"
- "*.toystore.io"
rules:
- matches:
- method: GET
path: { value: "/v1/", type: PathPrefix }
- method: POST
path: { value: "/v1/", type: PathPrefix }
backendRefs:
- name: toystore
port: 80
- matches:
- path: { value: "/assets/", type: PathPrefix }
backendRefs:
- name: toystore
port: 80
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: route-2
spec:
parentRefs:
- namespace: istio-system
name: gw-1
- namespace: istio-system
name: gw-2
hostnames:
- status.io
- status.local
rules:
- backendRefs:
- name: toystore
port: 80
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: route-3
spec:
parentRefs:
- namespace: istio-system
name: gw-2
rules:
- matches:
- path: { value: "/v1/", type: PathPrefix }
- path: { value: "/v2/", type: PathPrefix }
backendRefs:
- name: toystore
port: 80
EOFCheck no WasmPlugins created at this stage: kubectl get wasmplugins -A
# No resources found④ Create
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
guicassolato
force-pushed
the
rlpv2-routeselectors
branch
3 times, most recently
from
185f46f to
61edeea
Compare
guicassolato
changed the title
* Change `common.Contains(slice []string, target string)` to any comparable type (using generics) * Define a `common.HTTPRouteRuleSelector` type that checks whether a `HTTPRouteMatch` selects a `HTTPRouteRule` or not * Define a `rlptools.HTTPRouteRulesFromRouteSelector` function that returns all rules from a HTTPRoute that a route selector selects (using `common.HTTPRouteRuleSelector`) * Modify `rlptools.conditionsFromLimit` to use `rlptools.HTTPRouteRulesFromRouteSelector` and generate wasm conditions for each combination of selected route rule match and hostname * Ensure all generated route conditions include a pattern for the hostnames (route selectors’, HTTPRoute’s or Gateway’s) * Ensure all generated route conditions include the user-defined `when` conditions
…te and complex ratelimitpolicy The httproute declares 2 rules and 2 hostnames. The RLP declares 2 limits: - one limit declares one counter, targets one of the httprouterules, for one hostname only, with an additional 'when' condition and counter qualifier; - the other limit declares 2 counters, targets the other httprouterule, for all hostnames, and states no additional 'when' condition nor counter qualifier.
guicassolato
force-pushed
the
rlpv2-routeselectors
branch
from
87bf616 to
0bbadd2
Compare
eguzki
requested changes
Jul 17, 2023
| @@ -20,7 +21,7 @@ var ( | |||
| WASMFilterImageURL = common.FetchEnv("RELATED_IMAGE_WASMSHIM", "oci://quay.io/kuadrant/wasm-shim:latest") | |||
| ) | |||
|
|
|||
| // WasmRules computes WASM rules from the policy and the targeted Route (which can be nil when a gateway is targeted) | |||
| // WasmRules computes WASM rules from the policy and the targeted route. | |||
| func WasmRules(rlp *kuadrantv1beta2.RateLimitPolicy, route *gatewayapiv1beta1.HTTPRoute) []wasm.Rule { | |||
There was a problem hiding this comment.
This method should return error as well. One of the use cases I found is when the route selector does not match any HTTPRoute rule (route)
There was a problem hiding this comment.
As an alternative, the route selectors validity could be evaluated in a early stage of the reconcilliation loop to report in the status when the selector does not select any route. With this approach, the WasmRules only returns rules
There was a problem hiding this comment.
Right now, it's simply skipping a route selector that does not select anything.
Instead of raising a error here, I'd advocate for a combination of the following:
- the alternative you suggest – i.e. checking for route selector mismatches early on; I'd say in a validating webhook;
- reporting in the status of the RLP about all limits that will not be applied due to route selector mismatch. This one because this reconciliation can be triggered by changes in the HTTPRoutes as well.
|
verification steps working |
|
Tested removing httproutes and rlp's to see how reconciliation handles and works as expected 💪 |
|
I think now I (fully) understand the route selector concept. We really need to document it clearly. If Example:
The traffic to be rate limited will be: |
|
Verification steps working, both guides! BTW, super useful to extract to a user guide 📖 |
…long to the targeted route
…duces 'endswith' pattern operator
Passes a list of hostnames into the call to the function that generates the wasm rules for a given RLP, notoriously to compute the conditions when to apply each limit. The list of hostnames is the domain intersection between the hostnames specified in the HTTPRoute and its parent gateway for which the wasm config is being built. The route selection considers this as a boundary, so it doesn’t generate rules for the wrong gateway/hostname. Fixes the computation of conditions when no HTTPRouteRule matches the route selectors.
…e_selectors.go` along with the `RouteSelector` type itself + no longer injecting a separate list of hostnames for avoiding building wasm rules for hostnames that do not apply, as this did not seem to belong to the route selector logic anyway.
Get all HTTPRoutes that are children of the Gateway and call the generation of the set of wasm rules (conditions and data for each limit) for each HTTPRoute
…ng the wasm rules for rlps that target a gateway
…P method does not match
…TTPRouteRules in the same order as the selectors select the rules
…tes that have a rlp of its own and avoid building wasmplugins when there are no rules to apply
guicassolato
force-pushed
the
rlpv2-routeselectors
branch
from
0bbadd2 to
98cbe4a
Compare
eguzki
approved these changes
Jul 20, 2023
3 tasks
KevFan
pushed a commit
to KevFan/kuadrant-operator
that referenced
this pull request
Aug 10, 2023
* reconciliation of route selectors for RLPs targeting HTTPRoutes * Change `common.Contains(slice []string, target string)` to any comparable type (using generics) * Define a `common.HTTPRouteRuleSelector` type that checks whether a `HTTPRouteMatch` selects a `HTTPRouteRule` or not * Define a `rlptools.HTTPRouteRulesFromRouteSelector` function that returns all rules from a HTTPRoute that a route selector selects (using `common.HTTPRouteRuleSelector`) * Modify `rlptools.conditionsFromLimit` to use `rlptools.HTTPRouteRulesFromRouteSelector` and generate wasm conditions for each combination of selected route rule match and hostname * Ensure all generated route conditions include a pattern for the hostnames (route selectors’, HTTPRoute’s or Gateway’s) * Ensure all generated route conditions include the user-defined `when` conditions * add tests for generating a wasmplugin config out of a complex httproute and complex ratelimitpolicy The httproute declares 2 rules and 2 hostnames. The RLP declares 2 limits: - one limit declares one counter, targets one of the httprouterules, for one hostname only, with an additional 'when' condition and counter qualifier; - the other limit declares 2 counters, targets the other httprouterule, for all hostnames, and states no additional 'when' condition nor counter qualifier. * generate wasm rules only for routeSelector-filtered hostnames that belong to the targeted route * fix: pattern expression for hostnames with the right operator - introduces 'endswith' pattern operator * fix: compute wasm rules only for the applicable hostnames Passes a list of hostnames into the call to the function that generates the wasm rules for a given RLP, notoriously to compute the conditions when to apply each limit. The list of hostnames is the domain intersection between the hostnames specified in the HTTPRoute and its parent gateway for which the wasm config is being built. The route selection considers this as a boundary, so it doesn’t generate rules for the wrong gateway/hostname. Fixes the computation of conditions when no HTTPRouteRule matches the route selectors. * do not generate wasm condition patterns for the hostname when all apply * do not repeat RLPs for each hostname within the wasm config * `rlptools.HTTPRouteRulesFromRouteSelector` moved to `api/v1beta2/route_selectors.go` along with the `RouteSelector` type itself + no longer injecting a separate list of hostnames for avoiding building wasm rules for hostnames that do not apply, as this did not seem to belong to the route selector logic anyway. * reconciliation of route selectors for RLPs targeting Gateways Get all HTTPRoutes that are children of the Gateway and call the generation of the set of wasm rules (conditions and data for each limit) for each HTTPRoute * match the gateway hostnames instead of the httproute ones when building the wasm rules for rlps that target a gateway * refactor: make HTTPRouteRuleSelector.Selects return sooner if the HTTP method does not match * refactor: ensure wasm rule conditions are generated out of selected HTTPRouteRules in the same order as the selectors select the rules * Prevent the usage of routeSelectors in RLPs that target a Gateway * do not generate conditions for gateway policy wasm rules from httproutes that have a rlp of its own and avoid building wasmplugins when there are no rules to apply * avoid adding rlps without any rules to the wasm config
KevFan
pushed a commit
to KevFan/kuadrant-operator
that referenced
this pull request
Aug 14, 2023
* reconciliation of route selectors for RLPs targeting HTTPRoutes * Change `common.Contains(slice []string, target string)` to any comparable type (using generics) * Define a `common.HTTPRouteRuleSelector` type that checks whether a `HTTPRouteMatch` selects a `HTTPRouteRule` or not * Define a `rlptools.HTTPRouteRulesFromRouteSelector` function that returns all rules from a HTTPRoute that a route selector selects (using `common.HTTPRouteRuleSelector`) * Modify `rlptools.conditionsFromLimit` to use `rlptools.HTTPRouteRulesFromRouteSelector` and generate wasm conditions for each combination of selected route rule match and hostname * Ensure all generated route conditions include a pattern for the hostnames (route selectors’, HTTPRoute’s or Gateway’s) * Ensure all generated route conditions include the user-defined `when` conditions * add tests for generating a wasmplugin config out of a complex httproute and complex ratelimitpolicy The httproute declares 2 rules and 2 hostnames. The RLP declares 2 limits: - one limit declares one counter, targets one of the httprouterules, for one hostname only, with an additional 'when' condition and counter qualifier; - the other limit declares 2 counters, targets the other httprouterule, for all hostnames, and states no additional 'when' condition nor counter qualifier. * generate wasm rules only for routeSelector-filtered hostnames that belong to the targeted route * fix: pattern expression for hostnames with the right operator - introduces 'endswith' pattern operator * fix: compute wasm rules only for the applicable hostnames Passes a list of hostnames into the call to the function that generates the wasm rules for a given RLP, notoriously to compute the conditions when to apply each limit. The list of hostnames is the domain intersection between the hostnames specified in the HTTPRoute and its parent gateway for which the wasm config is being built. The route selection considers this as a boundary, so it doesn’t generate rules for the wrong gateway/hostname. Fixes the computation of conditions when no HTTPRouteRule matches the route selectors. * do not generate wasm condition patterns for the hostname when all apply * do not repeat RLPs for each hostname within the wasm config * `rlptools.HTTPRouteRulesFromRouteSelector` moved to `api/v1beta2/route_selectors.go` along with the `RouteSelector` type itself + no longer injecting a separate list of hostnames for avoiding building wasm rules for hostnames that do not apply, as this did not seem to belong to the route selector logic anyway. * reconciliation of route selectors for RLPs targeting Gateways Get all HTTPRoutes that are children of the Gateway and call the generation of the set of wasm rules (conditions and data for each limit) for each HTTPRoute * match the gateway hostnames instead of the httproute ones when building the wasm rules for rlps that target a gateway * refactor: make HTTPRouteRuleSelector.Selects return sooner if the HTTP method does not match * refactor: ensure wasm rule conditions are generated out of selected HTTPRouteRules in the same order as the selectors select the rules * Prevent the usage of routeSelectors in RLPs that target a Gateway * do not generate conditions for gateway policy wasm rules from httproutes that have a rlp of its own and avoid building wasmplugins when there are no rules to apply * avoid adding rlps without any rules to the wasm config
KevFan
pushed a commit
to KevFan/kuadrant-operator
that referenced
this pull request
Aug 14, 2023
* reconciliation of route selectors for RLPs targeting HTTPRoutes * Change `common.Contains(slice []string, target string)` to any comparable type (using generics) * Define a `common.HTTPRouteRuleSelector` type that checks whether a `HTTPRouteMatch` selects a `HTTPRouteRule` or not * Define a `rlptools.HTTPRouteRulesFromRouteSelector` function that returns all rules from a HTTPRoute that a route selector selects (using `common.HTTPRouteRuleSelector`) * Modify `rlptools.conditionsFromLimit` to use `rlptools.HTTPRouteRulesFromRouteSelector` and generate wasm conditions for each combination of selected route rule match and hostname * Ensure all generated route conditions include a pattern for the hostnames (route selectors’, HTTPRoute’s or Gateway’s) * Ensure all generated route conditions include the user-defined `when` conditions * add tests for generating a wasmplugin config out of a complex httproute and complex ratelimitpolicy The httproute declares 2 rules and 2 hostnames. The RLP declares 2 limits: - one limit declares one counter, targets one of the httprouterules, for one hostname only, with an additional 'when' condition and counter qualifier; - the other limit declares 2 counters, targets the other httprouterule, for all hostnames, and states no additional 'when' condition nor counter qualifier. * generate wasm rules only for routeSelector-filtered hostnames that belong to the targeted route * fix: pattern expression for hostnames with the right operator - introduces 'endswith' pattern operator * fix: compute wasm rules only for the applicable hostnames Passes a list of hostnames into the call to the function that generates the wasm rules for a given RLP, notoriously to compute the conditions when to apply each limit. The list of hostnames is the domain intersection between the hostnames specified in the HTTPRoute and its parent gateway for which the wasm config is being built. The route selection considers this as a boundary, so it doesn’t generate rules for the wrong gateway/hostname. Fixes the computation of conditions when no HTTPRouteRule matches the route selectors. * do not generate wasm condition patterns for the hostname when all apply * do not repeat RLPs for each hostname within the wasm config * `rlptools.HTTPRouteRulesFromRouteSelector` moved to `api/v1beta2/route_selectors.go` along with the `RouteSelector` type itself + no longer injecting a separate list of hostnames for avoiding building wasm rules for hostnames that do not apply, as this did not seem to belong to the route selector logic anyway. * reconciliation of route selectors for RLPs targeting Gateways Get all HTTPRoutes that are children of the Gateway and call the generation of the set of wasm rules (conditions and data for each limit) for each HTTPRoute * match the gateway hostnames instead of the httproute ones when building the wasm rules for rlps that target a gateway * refactor: make HTTPRouteRuleSelector.Selects return sooner if the HTTP method does not match * refactor: ensure wasm rule conditions are generated out of selected HTTPRouteRules in the same order as the selectors select the rules * Prevent the usage of routeSelectors in RLPs that target a Gateway * do not generate conditions for gateway policy wasm rules from httproutes that have a rlp of its own and avoid building wasmplugins when there are no rules to apply * avoid adding rlps without any rules to the wasm config
KevFan
pushed a commit
to KevFan/kuadrant-operator
that referenced
this pull request
Aug 16, 2023
* reconciliation of route selectors for RLPs targeting HTTPRoutes * Change `common.Contains(slice []string, target string)` to any comparable type (using generics) * Define a `common.HTTPRouteRuleSelector` type that checks whether a `HTTPRouteMatch` selects a `HTTPRouteRule` or not * Define a `rlptools.HTTPRouteRulesFromRouteSelector` function that returns all rules from a HTTPRoute that a route selector selects (using `common.HTTPRouteRuleSelector`) * Modify `rlptools.conditionsFromLimit` to use `rlptools.HTTPRouteRulesFromRouteSelector` and generate wasm conditions for each combination of selected route rule match and hostname * Ensure all generated route conditions include a pattern for the hostnames (route selectors’, HTTPRoute’s or Gateway’s) * Ensure all generated route conditions include the user-defined `when` conditions * add tests for generating a wasmplugin config out of a complex httproute and complex ratelimitpolicy The httproute declares 2 rules and 2 hostnames. The RLP declares 2 limits: - one limit declares one counter, targets one of the httprouterules, for one hostname only, with an additional 'when' condition and counter qualifier; - the other limit declares 2 counters, targets the other httprouterule, for all hostnames, and states no additional 'when' condition nor counter qualifier. * generate wasm rules only for routeSelector-filtered hostnames that belong to the targeted route * fix: pattern expression for hostnames with the right operator - introduces 'endswith' pattern operator * fix: compute wasm rules only for the applicable hostnames Passes a list of hostnames into the call to the function that generates the wasm rules for a given RLP, notoriously to compute the conditions when to apply each limit. The list of hostnames is the domain intersection between the hostnames specified in the HTTPRoute and its parent gateway for which the wasm config is being built. The route selection considers this as a boundary, so it doesn’t generate rules for the wrong gateway/hostname. Fixes the computation of conditions when no HTTPRouteRule matches the route selectors. * do not generate wasm condition patterns for the hostname when all apply * do not repeat RLPs for each hostname within the wasm config * `rlptools.HTTPRouteRulesFromRouteSelector` moved to `api/v1beta2/route_selectors.go` along with the `RouteSelector` type itself + no longer injecting a separate list of hostnames for avoiding building wasm rules for hostnames that do not apply, as this did not seem to belong to the route selector logic anyway. * reconciliation of route selectors for RLPs targeting Gateways Get all HTTPRoutes that are children of the Gateway and call the generation of the set of wasm rules (conditions and data for each limit) for each HTTPRoute * match the gateway hostnames instead of the httproute ones when building the wasm rules for rlps that target a gateway * refactor: make HTTPRouteRuleSelector.Selects return sooner if the HTTP method does not match * refactor: ensure wasm rule conditions are generated out of selected HTTPRouteRules in the same order as the selectors select the rules * Prevent the usage of routeSelectors in RLPs that target a Gateway * do not generate conditions for gateway policy wasm rules from httproutes that have a rlp of its own and avoid building wasmplugins when there are no rules to apply * avoid adding rlps without any rules to the wasm config
guicassolato
added a commit
that referenced
this pull request
Aug 21, 2023
* rpl v2 CRD * RLP CRD v2: WhenConditionOperator only eq and neq * controller-gen paths for v1beta2 as well * minor enhancement about logging only in debug mode * rlp v1beta2 controller * WASM plugin configuration object v2 * bundle update * fixup! bundle update * fix tests * WASMPlugin update to camel case * fix integration tests * wasm types moved to a common package * different selectors share type: ContextSelector --------- Co-authored-by: Eguzki Astiz Lezaun <[email protected]> * [rlp-v2] WasmPlugin reconciliation (#204) * reconciliation of route selectors for RLPs targeting HTTPRoutes * Change `common.Contains(slice []string, target string)` to any comparable type (using generics) * Define a `common.HTTPRouteRuleSelector` type that checks whether a `HTTPRouteMatch` selects a `HTTPRouteRule` or not * Define a `rlptools.HTTPRouteRulesFromRouteSelector` function that returns all rules from a HTTPRoute that a route selector selects (using `common.HTTPRouteRuleSelector`) * Modify `rlptools.conditionsFromLimit` to use `rlptools.HTTPRouteRulesFromRouteSelector` and generate wasm conditions for each combination of selected route rule match and hostname * Ensure all generated route conditions include a pattern for the hostnames (route selectors’, HTTPRoute’s or Gateway’s) * Ensure all generated route conditions include the user-defined `when` conditions * add tests for generating a wasmplugin config out of a complex httproute and complex ratelimitpolicy The httproute declares 2 rules and 2 hostnames. The RLP declares 2 limits: - one limit declares one counter, targets one of the httprouterules, for one hostname only, with an additional 'when' condition and counter qualifier; - the other limit declares 2 counters, targets the other httprouterule, for all hostnames, and states no additional 'when' condition nor counter qualifier. * generate wasm rules only for routeSelector-filtered hostnames that belong to the targeted route * fix: pattern expression for hostnames with the right operator - introduces 'endswith' pattern operator * fix: compute wasm rules only for the applicable hostnames Passes a list of hostnames into the call to the function that generates the wasm rules for a given RLP, notoriously to compute the conditions when to apply each limit. The list of hostnames is the domain intersection between the hostnames specified in the HTTPRoute and its parent gateway for which the wasm config is being built. The route selection considers this as a boundary, so it doesn’t generate rules for the wrong gateway/hostname. Fixes the computation of conditions when no HTTPRouteRule matches the route selectors. * do not generate wasm condition patterns for the hostname when all apply * do not repeat RLPs for each hostname within the wasm config * `rlptools.HTTPRouteRulesFromRouteSelector` moved to `api/v1beta2/route_selectors.go` along with the `RouteSelector` type itself + no longer injecting a separate list of hostnames for avoiding building wasm rules for hostnames that do not apply, as this did not seem to belong to the route selector logic anyway. * reconciliation of route selectors for RLPs targeting Gateways Get all HTTPRoutes that are children of the Gateway and call the generation of the set of wasm rules (conditions and data for each limit) for each HTTPRoute * match the gateway hostnames instead of the httproute ones when building the wasm rules for rlps that target a gateway * refactor: make HTTPRouteRuleSelector.Selects return sooner if the HTTP method does not match * refactor: ensure wasm rule conditions are generated out of selected HTTPRouteRules in the same order as the selectors select the rules * Prevent the usage of routeSelectors in RLPs that target a Gateway * do not generate conditions for gateway policy wasm rules from httproutes that have a rlp of its own and avoid building wasmplugins when there are no rules to apply * avoid adding rlps without any rules to the wasm config * fix: do not use gateway name nor host in the RL domain Fixes the reconciliation of the Limitador CR, pairing it with the reconciled wasm config (WasmPlugin CR), so - rate limit definitions won't be duplicated in the Limitador CR; - limits can be defined crossing gateways and hostnames and yet be treated as the same limit in Limitador (case of simple RLPs that target HTTPRoutes with multiple Gateway parent refs) * Limit names in the Limitador conditions and RL request data generated in the format: limit.<limit-name>__<hash>, where <limit-name> is sanitised to include only characters allowed by Limitador for the identifiers and <hash> is generated out of the original limit name to avoid breaking uniqueness of the name after sanitisation. * fix: missing rebase changes & update istio deps For some reason after rebase, there is some dependency issue. This was fixed by updating the istio dep to https://github.com/istio/istio/releases/tag/1.17.5 * fix: lint issues * refactor: lint change for CountersAsStringList() and deleteLimits() Co-authored-by: Guilherme Cassolato <[email protected]> --------- Co-authored-by: Eguzki Astiz Lezaun <[email protected]> Co-authored-by: Guilherme Cassolato <[email protected]> Co-authored-by: KevFan <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reconciliation of the Istio WasmPlugin CR with wasm rules generated for each limit definition from the affecting RLPs – triggers based on
routeSelectorsandwhenconditions, and RL data (descriptors) to activate the limits in Limitador and additional counter qualifiers.Implements Direct Policy Attachment of RLPs targeting a HTTPRoute or a Gateway (WasmPlugin part).
Highlights
whenconditions and HTTPRouteRules selected by therouteSelectors, and data that activates the limit in Limitador plus additional counter qualifiersendswith)routeSelectorsin RLPs that target a GatewayVerification steps
Topology:
① Setup:
② Create a second Gateway:
③ Create a HTTPRoute:
(Notice the route specifies 2 gateway parents and 3 host names, where all 3 host names bind the route to the
istio-ingressgatewaygateway and one of them to theinternal-gatewaygateway.)④ Create the RateLimitPolicy:
(Notice one of the limits applies to only one host name.)
⑤ Verify the Limitador CR was reconciled correctly:
Expected output
⑥ Verify the WasmPlugin CRs were reconciled correctly:
Expected output
Expected output
Closes #200
Relates to #156